HTTP & HTTPS 区别于联系
定义
http: 以明文的形式传递信息（可能数据劫持，然后从服务器返回给用户的数据中加入广告）
https: 通过密文传递信息（一开始考虑使用非对称加密）
1. https 工作流程
配置有公钥和私钥：并且采用非对称加密。
公钥加密 ->私钥解密 公钥加密 ×公钥解不了密
私钥加密 ->公钥解密 私钥也解不了
2. 服务器与浏览器中的HTTPS(SSL)
服务器先把自己公钥发给浏览器
浏览器生成一个随机数据
用公钥对随机数加密
发送给服务器
服务器用自己的私钥解密
如此双方得到了同样的随机数据 既随机加密数据的密钥 ->用该密钥对称加密所需要传递的数据
这是一套独立于http的流程 即安全套接字层 Secure Sokect Layer SSL
SSL1.0(1994)->SSL2.0(1995)->SSL3.0(1996)->TLS1.0(1999)又称”SSL3.1”
3. 存在问题
例如
服务器发送公钥时候被中间拦截
转发给浏览器虚假的公钥
浏览器不认识公钥是谁的直接使用虚假的公钥加密随机数然后发送给服务器
发送途中再拦截浏览器使用虚假公钥加密的随机数
使用虚假的私钥解密得到随机数
再使用服务器的公钥加密回去发回给服务器
问题出在 公钥不能表示自己属于谁？
解决办法 引入第三方 CA
CA（Certificate Authority）
1. 使用CA后工作流程
服务器将自己信息
去找第三方机构（CACertificate Authority）
CA（拥有自己的公私钥对）用自己的私钥对数据集合进行加密得到的密文（称之为签名）然后把带着签名的数据集合发给服务器
服务器把TLS证书传递给浏览器
浏览器拿着CA给的公钥对密文进行解密
如果解密的结果和证书中的明文一直则通过 如果不通过风险提示！
-然后从证书中提取服务器的公钥加密随机数发送 协商出密钥进行传输。
2. CA服务商
CA google microsoft
3. CA存在问题
浏览器内置信任的CA证书（此时CA便是中心，问题CA是否值得100%信任？）
问题最终还是要去中心化
CT(Certificate Transparency)
1. 工作流程
这种操作看上去如同套娃 还是没有做到真正的CT 于是再日志服务中引入 墨克尔树
在这个墨克尔树中修改任意记录根哈希值都会改变 这样可以做到相对意义上得去中心化
2. CT机制
一开始CT作为CA证书中的可选项目CA机构还可以选择不向日志服务上报而逃避审查 现在不行了
